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REMARKS 

I. STATUS OF THE CLAIMS 

Claims 1-11 and 22-38 are currently pending. 

II. REJECTION OF CLAIMS UNDER 35 USC 1 12, SECOND PARAGRAPH 

The Examiner asserts that the term "type" in the claims is indefinite. 

As indicated on page 14, lines 20-28, of the specification, a customer can have many 
different "types" of accounts, and many different accounts of the same type. For example, 
different types of accounts can include credit card accounts, mortgage accounts, long distance 
telephone accounts, cellular telephone accounts and cable TV accounts. A customer can have, 
for example, three different credit card accounts, or two different cellular telephone accounts. 

It is believed that such a description of different "types" of accounts in the specification is 
within the common, everyday use to the average person, and would clearly be understood by a 
person of ordinary skill in the art to which the present invention pertains. For example, it would 
be understood that a credit card account and a mortgage account are different "types" of 
accounts. Therefore, it is respectfully submitted that the use of the term "type" in the claims is in 
compliance with 35 USC 112, second paragraph. 

In the rejection, the Examiner refers to MPEP 2173.05(b), Section E. However, each 
case cited and each example described in this section of the MPEP refers to chemical 
technology. By contrast, the present invention relates to business, and to computer/software 
technology. In the specific business to which the present invention pertains, it is respectfully 
submitted that the term "type" to describe different "types" of account, would be well-understood. 

It is respectfully submitted that MPEP 2173.05(b) also sets forth the following: 

"The fact that claim language, including terms of degree, may not be precise, does not 
automatically render the claim indefinite under 35 USC, second paragraph. Acceptability of the 
claim language depends on whether one of ordinary skill in the art would understand what is 
claimed, in light of the specification." 

In view of the above, it is respectfully submitted that the use of the term "type" in the 
claims is in compliance with 35 USC 112, second paragraph. Therefore, it is respectfully 
requested that the Examiner withdraw the rejection. 
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III. REJECTION OF CLAIMS UNDER 35 USC 102(E) AS BEING ANTICIPATED BY 
WALKER, USP 6,088,686 

The present invention as recited, for example, in claim 1 , relates to a computer- 
implemented decision management process for evaluating a customer of an organization having 
more than one account. In a single pass, the process evaluates the customer and each of the 
accounts of the same type with the same strategy, different types of accounts being evaluated 
with different strategies. Then, the process takes an action in accordance with a result of the 
evaluation. 

A "single pass" indicates that, in the evaluation of a customer, the required customer and 
account data is retrieved and loaded once, prior to doing the customer evaluation. After the 
data is loaded, customer and account rules can be run interactively and interchangeably against 
the data. See for example, page 17, line 19, through page 18, line 6, of the specification. 

As described, for example, on page 17, line 19, through page 18, line 6, of the 
specification, such use of a single pass is particularly important where a respective customer 
has many accounts. Thus, the process does not have to run multiple times with dependencies 
between previous and subsequent occurrences. 

Therefore, the present invention as recited, for example, in claim 1 , uses a single pass to 
evaluate each account of the same type of a customer with the same strategy. Moreover, in the 
single pass, different types of accounts of the customer are evaluated with different strategies. 

For example, in the specific example in FIG.10 of the application, an iterative function 
(see "next iteration" in FIG. 10) is used to implement a single pass. In steps 222 and 224, the 
type of account is taken into consideration. In FIG. 10, different strategies are used to evaluate 
credit card accounts and mortgage accounts, respectively. Via the iterative function in FIG. 10, 
the process loops back so that each account of the customer is evaluated in a single pass, with 
different types of accounts being evaluated with different strategies. Therefore, via the use of a 
single pass, the required customer and account data is retrieved and loaded once, prior to doing 
the evaluation for the various accounts. 

To summarize, the present invention relates to the use of a SINGLE PASS to evaluate 
each account of the customer of the SAME TYPE WITH THE SAME STRATEGY, and 
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DIFFERENT TYPES OF ACCOUNTS of the customer WITH DIFFERENT STRATEGIES. 

Walker relates to processing of applications for products and services offered by a 
financial institution. See, for example, the Abstract, and column 5, lines 66, through column 6, 
line 15, of Walker. The overall processing of applications is shown in the flow chart which runs 
from FIGS. 40-51 of Walker. 

However, Walker shows the processing of only a SINGLE application by an applicant. 
The process does NOT show the processing of multiple applications by the same applicant. 

For example, FIGS. 40-51 of Walker show the various processes which are executed to 
determine if a respective application is accepted. Final processing is shown in FIG. 51. 
Referring to FIG. 51, after a decision on a processed application is made, customer information 
is updated in step 2258. Then, the processing ends in step 2260. 

It is important to note that the final processing in FIG. 51 of Walker does NOT loop back 
to FIG. 40 to begin processing of another application of the same applicant. This is significantly 
different than the present invention, where a plurality of accounts of an applicant are evaluated 
in a single pass. 

Moreover, if some type of loop back was considered in Walker, it is unclear where such a 
loop back would return. For example, steps 2002 to 2006 in FIG. 40 of Walker relate to the 
loading of customer data. If the system of Walker would require a loop back to steps 2000 or 
2002, such a loop back would not represent a "single pass," since customer data would have to 
be reloaded in the system to evaluate another application. This operation would be contrary to 
the present invention as recited, for example, in claim 1 . Please note that Walker also retrieves 
data in other steps, such as in steps 2092 and 2094 in FIG. 43. 

Therefore, it is respectfully submitted that Walker does not disclose or suggest the use of 
a single pass to evaluate a plurality of accounts of a customer, as in the claimed invention. 

In view of the above, it is respectfully submitted that the rejection is overcome. 
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IV. 



IDS 



Please note that an IDS was filed on April 3, 2002. It is respectfully requested that the 
Examiner acknowledged the IDS. 

V. CONCLUSION 

In view of the above, it is respectfully submitted that the application is in condition for 
allowance, and a Notice of Allowance is earnestly solicited. 

If any further fees are required in connection with the filing of this response, please 
charge such fees to our Deposit Account No. 19-3935. 



Respectfully submitted, 



STAAS & HALSEY LLP 



700 Eleventh Street, NW, Suite 500 
Washington, D.C. 20001 
(202) 434-1500 
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